IETF Logo Mail Archive

Re: [manet] AD Review of draft-ietf-manet-olsrv2-multipath-11

"Alvaro Retana (aretana)" <aretana@cisco.com> Thu, 20 April 2017 20:35 UTC

Return-Path: <aretana@cisco.com>
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 315BC131681; Thu, 20 Apr 2017 13:35:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level:
X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92T_2l67S2Kw; Thu, 20 Apr 2017 13:35:03 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F31AF13167D; Thu, 20 Apr 2017 13:35:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16916; q=dns/txt; s=iport; t=1492720503; x=1493930103; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=awi7GeNucc3tNt00MyvXoD9OlETJb2+3stEaO3jU1R4=; b=fkmBxZva1qdpcMg0pVRoXZSOYdlW/xYqu0CYr6WD5SfSEgzvzJJz6D6q Ixk3XXhJ/7Zo3Euj2F/KWbq+s9LumhLGWLaCV7Scv3FS3IWYqzcVVYDo9 mpEZfDU7XcAattb6w8oK5Np8tDc7TE4Ae8fCHqiTW29HpS1NHpWx7mBBV Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DKAQAwG/lY/5xdJa1dGQEBAQEBAQEBAQEBBwEBAQEBgm5mYYEMB4NgihWRRpBPhTWCDyyFeAIag2M/GAECAQEBAQEBAWsohRYGI0gOEAIBBgI/AwICAjAUEQIEDgWKHA6MPZ1dgiYringBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYZTgV0rC4Jjh10ugjEFlkCGdAGHFItukVWUEwEfOIEFYxVVAYRUHIFjdYghgQ0BAQE
X-IronPort-AV: E=Sophos;i="5.37,227,1488844800"; d="scan'208,217";a="413144049"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Apr 2017 20:34:58 +0000
Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v3KKYwxr011649 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 20 Apr 2017 20:34:58 GMT
Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 20 Apr 2017 15:34:57 -0500
Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Thu, 20 Apr 2017 15:34:57 -0500
From: "Alvaro Retana (aretana)" <aretana@cisco.com>
To: Jiazi Yi <jiazi@jiaziyi.com>
CC: "draft-ietf-manet-olsrv2-multipath@ietf.org" <draft-ietf-manet-olsrv2-multipath@ietf.org>, "manet-chairs@ietf.org" <manet-chairs@ietf.org>, Stan Ratliff <sratliff@idirect.net>, "manet@ietf.org" <manet@ietf.org>
Thread-Topic: AD Review of draft-ietf-manet-olsrv2-multipath-11
Thread-Index: AQHSrMBYAGgO+lU2M0uWMpAvOFwcc6HNQYqAgAGg3IA=
Date: Thu, 20 Apr 2017 20:34:57 +0000
Message-ID: <2BB3A607-4578-40B3-ACE2-2807911361F5@cisco.com>
References: <1F0A54FE-B275-4203-AC7B-347101217BEF@cisco.com> <6BE8ABAF-6672-4994-AFD3-1FA0BA9B865E@jiaziyi.com>
In-Reply-To: <6BE8ABAF-6672-4994-AFD3-1FA0BA9B865E@jiaziyi.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.1f.0.170216
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.117.15.6]
Content-Type: multipart/alternative; boundary="_000_2BB3A607457840B3ACE22807911361F5ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/OHQsgv_0__7QxntTlGuCc8lmk0o>
Subject: Re: [manet] AD Review of draft-ietf-manet-olsrv2-multipath-11
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Mobile Ad-hoc Networks <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/manet/>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Apr 2017 20:35:05 -0000

On 4/19/17, 11:42 AM, "Jiazi Yi" <jiazi@jiaziyi.com<mailto:jiazi@jiaziyi.com>> wrote:


Jiazi:

Hi!

I just have a couple comments – look for [a].  You can treat them as Last Call comments.

I am going to start the IETF Last Call.

Thanks!!

Alvaro.




[a] New: In 8.1  s/MUST not/MUST NOT



…

M2. MAX_SRC_HOPS .  Both Section 5.1. (Router Parameters) and Section 9. (Configuration Parameters) say that “For IPv6 networks, it MUST be set to 0, i.e., no constraint on maximum number of hops.”  What about potential MTU/fragmentation issues?  RFC6554 (in Section 4.1. (Generating Source Routing Headers)) does talk about a maximum path length.

We added some text considering the MTU issue:

It is RECOMMENDED to use MTU sizes considering the source routing header to avoid fragmentation. Depending on the size of the routing domain, the MTU should be at least 1280 + 40 (for outer IP header) + 16 * diameter of the network in number of hops (for source routing header). If the links in the network have different MTU sizes, by using technologies like Path MTU Discovery, the routers are able to be aware of the MTU along the path. The size of the datagram plus the size of IP headers (including the source routing header) SHOULD NOT exceed the minimum MTU along the path.


[a] I don’t think we need the Normative language, otherwise I think the text looks good.




…
M4. Section 6.2.2. (Source Routing Header in IPv6) says that the routing header from RFC6554 is used with IPv6 Routing Type 254 (experimental).  Why?   I’m asking because RFC4727 says that the experimental values “MUST NOT be shipped as defaults in implementations” – not only do implementations exist, but the purpose of this Experimental document is to gather experience form real deployments.  Short of asking for a new Routing Type, why isn’t the one already assigned to RFC6554 used?

Ah, I didn’t know that text in RFC4727 before. I asked such question to one of the 6man co-chairs, Ole, and he suggested using such experimental code point (https://mailarchive.ietf.org/arch/msg/manet/YcpyzC4T3VUVEsEN_YgyizN4pBo)
Now we are using the routing type used by RFC6554.

[a] Note that 6.2.2. still says 254 – you did change it in 8.4.





…



M10. IANA Considerations.  Sections 12.1. (Expert Review: Evaluation Guidelines) and 12.3. (Routing Type) are not needed as this document is not specifying any new space that requires DE review (the assignment should be done under DE review, but that is specified elsewhere), and the Routing Type is already assigned by IANA.

Removed.

[a] You didn’t remove 12.1.





…



- s/RFC2460/draft-ietf-6man-rfc2460bis

Fixed.

[a] Sorry, I think we want to go back to RFC2460.  I thought that document was going to be processed faster than it is, so we could end up processing/approving this document before rfc2460bis.

v2.23.0 | Report a Bug | By Email